When high-value digital content, such as entertainment media content, is distributed, that content must be protected against unauthorized distribution and use to protect the rights of the copyright holder. Encryption is often used as a method of protecting content against unauthorized use as only those users or devices which have the proper decryption key are able to utilize the encrypted content. This creates the issue of how to get the proper key only to those users or devices which are allowed to utilize the content. The process of determining which users or devices should be given the key is called authentication and the process of securely giving the key to the device that will be decrypting the content is called a key exchange.
Authentication over a network is an important part of security for systems that allow client devices to access resources on the network. Authentication is generally accomplished by verifying something a user knows, such as a password, something a user is, such as a fingerprint, or something a user has, such as a smart-card.
As an example, a typical login to a computer system may rely only on something that the user knows. This authentication process usually consists of a user name and password being entered by the user. It is becoming more common, however, to require a fingerprint or retinal scan as a part of the login process which adds something that the user is. This type of authentication, which requires a user to enter a password or biometric information each time the want to access protected content, is undesirable for entertainment content because of the “hassle-factor” for the user.
Using the last type of authentication, something the user has, and embedding that something inside of a client device eliminates this “hassle-factor.” The mere fact that the user possesses the device is enough to authorize the user to receive the content. Extra security requirements are necessary to secure the data within the device from attack, but the extra requirements are generally deemed worthwhile for an entertainment application as it is much more convenient for the user. The client device may have secret data (e.g. secret keys shared with the authenticating server) which must never be revealed, as well as non-secret but sensitive data (e.g. the authenticating server's public key) which must be stored in a tamper-proof way.
One common type of data stored in a client device for authentication purposes is referred to as a digital certificate. Typically a digital certificate contains data that has been cryptographically signed to make it very difficult to tamper with the content of the certificate without detection. The digital certificate can be sent to a local server as evidence that the device should be authenticated. In most prior art, the local server would then send this certificate to a central validation authority which knows the secret for verifying that the certificate has not been tampered with. This creates a problem for many applications where it is either not possible or it is too time consuming to connect to the central validation server. In other cases, the local server may keep a cache of valid certificates which can be compared to the digital certificate that is received from the client device. Because in most cases the digital certificate in each client device is unique, this creates a data management issue due to the number of potential certificates that might need to be cached to have the proper certificate when a particular authorized unit is purchased by the user. In yet another approach, the local server knows the secret which is required to validate the certificate. This can create a much less secure environment if the local server does not ever receive anything from the central validation authority. The local server can then validate any certificate, giving no way for the central validation authority to revoke a certificate that once was valid.
This problem points out an additional item that must be dealt with by any authentication technique based on digital certificates. Some method must be created for revoking certificates that have expired, been canceled, or that have been rendered invalid by being broken by hackers. The prior art has dealt with this problem by creating and distributing certificate revocation lists (CRLs) to all local servers. A CRL is simply a list of the certificates which are no longer valid. Since the contents of these lists must be kept from being tampered with, they themselves must be cryptographically signed and validated by the local server creating yet another authentication issue. The distribution of these CRLs also creates a vulnerability because if a local server can be blocked from receiving a CRL, it might authenticate a client device that should be rejected.
Once a client device has been authenticated, a key exchange must take place to provide the client device with the key needed to decrypt the content. This task must also be accomplished in a secure fashion to ensure that no third party can intercept the key and use it to access content to which they are not entitled.
So there remains a need for an improved method of authenticating a client device in a way that does not require a connection to a central validation authority at the time the client device is authenticated, yet can still reliably deny permission to a client device that has had its rights revoked. This method should also put minimal computing and memory requirements client devices to enable them to be manufactured and sold at consumer price-points.